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Abstract of EP1 054332 

Database (4) comprises objects (5) with standard attributes (6) with the database able to be interrogated 
by an application, user, etc. The objects (5) are characterized by specific attributes (20) with the same 
external structure as standard attributes the internal structure of which enables the administration and 
definition of components (21 ) independent of the database. 
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(54) Systeme et precede de gestlon d'attributs dans un environnement oriente objet 



(57) La pr6sente Invention conceme un proc6d6 de 
gestlon d'une base de donnees (4) ou annuaire ou equi- 
valent comportant des objets (5) caracterises par des 
attributs standards (6). la base etant apte ^ etre interro- 
gee par une application, un utilisateur ou autre, appel^ 
entitd, consistant k caractdriser les objets (5) par des 



attributs sp§cifiques (20) dits attributs opaques (20). 
prdsentant la mdme structure exteme que les attributs 
standards (6) et dont la structure interne penmet de de- 
finir et administrer des composants (21) de maniere in- 
dependante k la base (4). 

La pr^sente invention conceme dgalement ie sys- 
tdme mettant en oeuvre ledit procedd. 



CM 
CO 
CO 

in 
o 

liJ 




FIG.1 



o>«M*M*Jw. !...»«. 7cnn« OAOie rea\ 



1 



EP 1 054 332 A1 



2 



Description 

[0001] La prdsente invention concerne le domains 
des bases de donnSes dans un environnement d'ordi- 
nateur orient6 objet. 

L'art anterieur 

[0002] Une base de donnees, un annuaire ou equiva- 
lent organise de nnanidre coherente des objets partagds 
par des utiiisateurs ou des applications. 
[0003] Un objet est une abstraction d'une donnde du 
monde r6ei. L'objet est caractdrise par une identity, un- 
6tat et un comportement. L'identitd d'un objet est reprd- 
sentd par un identifiant unique et invariant qui pemnet 
de r6fdrencer l'objet inddpendamment des autres ob- 
jets. Les valeurs de I'^tat d*un objet sont donnees par 
des attrlbuts. Le comportement d'un objet est d^fini par 
un ensemble d'op^rations applicables k l'objet. Les ob- 
jets similaires sont group^s en ctasse. Une classe d^crit 
la structure et le comportement commun d'objets. Les 
objets et les attribute sont ddfinis dans un schema de la 
base. 

[0004] Dans les bases de donnees actuelles, tous les 
attributs sont d^ciar^s dans le schema de la base. 
[0005] Or, la complexity et revolution rapide des in- 
formations contenues dans une base de donnees sou- 
Invent de nombreux probl^mes : 
[0006] La description du schema de la base est fre- 
quemment modiflde ce qui ndcessite une gestion per- 
manente et couteuse de la base et entraTne une gdne 
pour les utiiisateurs et administrateurs. 
[0007] Des objets de versions diff^rentes sont sus- 
ceptibles d'dtre geres par une meme base. Le probl&me 
de gestion de versions se complique avec la replication 
des bases dans un environnement distribud et plus par- 
ticulierement lorsque les diffdrentes versions se situent 
sur des machines diff^rentes. 
[OOOS] L'utilisateur a souvent besoin d*acceder rapi- 
dement k une suite d'attributs d'un objet donnd. La base 
est sollicitee pour la recherche de chacun des attributs. 
II en rdsulte un encombrement dans la consultation de 
(a base, une lenteur dans I'obtention d'une rdponse k 
une Interrogation. 

[0009] 11 serait avantageux que des composants de 
types diff^rents (chaine de caract^res. entier, boo- 
Iden...) soient stockds dans un mdme attribut, ce qui 
n'est pas realisable avec les systemes actueis connus. 
[0010] L'origine. I'integrite ou la confidentiality des in- 
formations stockSes dans la base ne sont garantles 
qu'apr&s application de techniques diverses sur les at- 
tributs, techniques rapportees, lourdes et couteuses. 
[0011] Un but de la prdsente invention est de permet- 
tre de modifier facilement et rapidement les informations 
associees k une classe d'objets. 
[001 2] Un autre but de la presente invention est d'ac- 
ceder rapidement k une suite d'attributs. 
[001 3] Un autre but est d'integrer des composants de 



differents types dans un meme attribut. 
[001 4] Un autre but de la presente invention est d'ad^ 
ministrer la cohabitation d'objets de versions differentes 
dans une mdme base ou des bases repliquees. 
5 [001 5] Un autre but est de garantir Torigine, I'integritd 
- et la confidentiality de I'information sans recours k des 
techniques rapportees. 

Resume de I'lnvention 

[001 6] Dans ce contexte, la presente invention propo- 
se un precede de gestion d'une base de donnees ou 
annuaire ou equivalent comportant des objets caracte^ 
rises par des attributs standards, la base etant apte k 

IS etre interrogee par une application, un utilisateur ou 
autre appele entite. caracterise en ce qu'il consiste k 
caracteriser les objets par des attributs specifiques dits 
attributs opaques, presentant la meme structure exter- 
ne que les attributs standards et dont la structure interne 

20 permet de definir et administrer des composants de ma- 
niere independante ei la base. 
[0017] La presente invention concerne le systdme In- 
formatique de mise en oeuvre du procedd selon inven- 
tion. 

25 [0018] La presente invention se rapporte egalement 
k un systeme Informatique comprenant au moins une 
machine munie d'une base de donnees ou annuaire ou 
equivalent susceptible d'etre interrogee par une appli- 
cation, un utilisateur ou autre, appeie entite, caracterise 

30 en ce quil comprend une interface de programmation 
au niveau applicatif API entre la base et I'entite compre- 
nant des f onctions d'acces k la base et des fonctions de 
gestion d'attributs standards et/ou d'attributs opaques. 



[0019] D'autres caracteristiques et avantages de I'in- 
vention apparaitronl k la lumidre de la description qui 
suit, donnee k titre d'exemple iilustratif et non limitatif 
40 de la presents invention, en reference aux dessins an- 
nexes dans lesquels: 

• la figure 1 est une vue schematique du systeme se- 
ton la presents invention : 

• ia figure 2 represente de maniere schematique la 
structure d'un attribut opaque du systeme selon la 
figure 1 ; 

• la figure 3 represente de maniere schematique des 
etapes du precede selon la presente invention. 

so 

Description d'une forme de reaiisatlon de I'lnven- 
tion 

[0020] Comme represente sur la figure 1 , la presente 
ss invention se rapporte k un systeme d'infomnation 1 dont 
Tenvironnement est de type orlenie objet. Le systeme 1 
comporte au moins une machine 2. Le terme « machine 
» est utilise dans un sens general pour designer tout 
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type d'ordinateurs ou equivalents. 
[0021] Le sysldme 1 peul §tre un syst6me dont i'en- 
vironnement est de type distribu^ ou local. Dans la for- 
me de realisation illustrde sur la figure 1 . ie syst^me 1 
de type distribud comprend trois machines 2a, 2b, 2c, s 
appel6es respectivement machine 2a annuaire, machi- 
ne 2b de stockage, machine 2c d'administration. Seuls 
les composants des machines 2 du systdme 1 caractd- 
ristiques de ia pr^sente invention seront d^crits, les 
autres composants 6tant connus de Thomme du metier. 
Les machines 2 sent relives entre elles au travers d'un 
r^seau 3 ; dans ia forme de realisation de la figure 1 , la 
machine 2a est relive aux machines 2b et 2c par le r§- 
seau 3. 

[0022] Le systdme 1 comporte une base de donndes 
ou un annuaire 4 ou Equivalent installd sur la machine 
2a annuaire. Dans la description qui suit, il sera fait re- 
ference k i'annuaire 4. L'annuaire 4 contient des objets 
5 caracterises par des attributs de type connu dits attri- 
buts standards 6. Dans Texemple illustrd sur la figure 1 , 
les informations sont structur^es en objets 5 integr^s 
dans I'annualre 4 suivant le module X500 connu ; ia ma- 
chine 2a annuaire communique avec les machines 2b 
de stoclcage et 2c d'administratlon au travers d'une in- 
terface 7 LDAR 

[0023] Des utilisateurs ou des applications diverses 
ou autres, appeies ci-apr^s entites 8 sont susceptibles 
d'interroger Tannuaire 4 directement sur la machine 2a 
annuaire I'hebergeant ou k partir d'autres machines 2b, 
2c. Dans {'example illustrd sur la figure 1 , une applica- 
tion 8 est instance sur la machine 2c d'administratlon et 
travaille avec les donn^es de I'annualre 4. Selon une 
forme de realisation particuli^re. I'application 8 est mu- 
nie d'une interface graphique 9. 
[0024] L'une des machines 2a. 2b ou 2c du systeme 
1 (machine 2b de stockage sur la figure 1 ) comprend un 
compilateur 10 de description et des moyens de stoc- 
kage 11 d'au moins un fichierl 2 source de description. 
[0025] L'une des machines 2a, 2b ou 2c du systeme 
1 (machine 2c d'administratlon sur la figure 1)comprend 
une interface de programmation au niveau applicatif, 
appeiee couramment interface AP1 1 3 munie d'au moins 
une fonction 14 de gestion et d'au moins une fonction 
15 d'acces k I'annuaire 4. des moyens 16 de memori- 
sation d'une structure 17 de communication entre Tin- 
terface AP1 13 et I'entite 8, une memoire tampon 18, un 
module de sEcuritd 19. 

[0026] Le precede selon la presente invention consis- 
te k caracteriser les objets 5 par des attributs specifi- 
ques 20 dits attributs opaques 20, presentant la meme 
structure exteme que les attributs standards 6 et dont 
la structure interne permet de d6flnir et administrer des 
composants 21 de mani^re Independante k i'annuaire 4. 
[0027] Les structures des attributs standards 6 sont 
de trois types : de type texte directement lisible par I'in- 
terfac07. de type binaire representant une unique infor- 
mation d'un type determine qui n'est pas directement 
lisible par I'interface 7, de type specialise requerant des 



contrdles de syntaxe. 

[0028] Le terme « structure externe » signifie que la 
structure de I'attribut opaque. 20 telle que vue par I'an- 
nuaire 4 et I'interface 7 est identique k la structure d'un 
attribut standard 6. Pour I'annuaire 4 et I'interface 7, les 
attributs opaques 20 presentent une structure externe 
de type binaire. Un attribut opaque 20 est considdre par 
I'interface 7 entre I'entite 8 et I'annuaire 4 comme un at- 
tribut standard 6. 

[0029] L'attribut opaque 20 est comparable k un 
container : des composants 21 sont introduits dans le 
container. Les composants 21 sont independants de la 
technologie ou de Torganlsation de I'annuaire 4. 11 est 
possible de rajouter des composants 21 dans l'attribut 
opaque 20 sans modifier le schema de i'annuaire 4. Les 
composants 21 introduits dans l'attribut opaque 20 peu- 
vent etre de types varies. 

[0030] L'objet 5 est identifie de maniere unique dans 
I'annuaire 4; les attributs opaques 20 sont cr66s k cha- 
que besoin specifique d'une entite 8. Le contenu des 
attributs opaques 20 depend de I'entite 8 contrairement 
k celui des attributs standards 6 dependant de I'annuai- 
re 4 et de son schema de base. 
[0031] L'attribut opaque, de type binaire pour I'inter- 
face 7. presente une structure interne determin^e sus- 
ceptible d'dtre exploitee par I'interface AP1 13, structure 
dans laquelle divers types de composants 21 sont clas- 
ses. 

[0032] Seion une forme de realisation de I'invention 
illustree sur la figure 2, la structure interne de l'attribut 
opaque 20 est constitude de trois parties : 

• un en-t§te 22 ; 

• une table 23 de caracteristiques des composants 

21; 

• un ensemble 24 de valeurs des composants 21 . 

[0033] La structure interne de l'attribut opaque est 
predefinie de maniere k retrouver les composants 21 
dans les informations de type binaire de l'attribut opa- 
que 20 comme vu plus haut. 

[0034] L'en-tete 22 fournit des informations generates 
sur I'attribut opaque 20 concern^ teiles que : 

• une version du tormalisme de la structure utilisee 
pour l'attribut opaque 20 et pour les composants 21 
contenus dans l'attribut opaque 20 concern^. La 
version assure une evolution de la structure de l'ob- 
jet et permet la compatibilite montante et descen- 
dante des structures comme il sera vu plus loin ; 

• une longueur en octets des donnees suivantes de 
I'en-tete (informations de securite, date de derni^re 
mise k jour ...) de mani^re k retrouver la table 23 
dans ies donnees binaires de l'attribut, comme vu 
plus haut ; 

• des Informations de securite assurant I'lntegrite, 
I'origine et la confi den tialite des composants conte- 
nus dans l'attribut opaque. Les attributs sont prote- 
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g6s d'alt^rations ou d'extractions non souhaitees. 
Oes services de signature et/ou de chiff rement sont 
susceptlbles d'etre mis en oeuvre. Las informations 
de s^curit^ permettent la signature de I'attribut de 
mani^re globale, ce qui ameliore les performances, s 
Les informations de securite sont par exemple in- 
dication d'une signature souhaitde ou non pour I'at- 
tribut, I'indication d'un chlffrement souhalt6 pour 
tous les composants de I'attribut ou seuiement cer- 
tains d'entre eux ou encore non souhaitd, la force 
des algorithmes utilises, les algorithmes utilises (si- 
gnature DSA, RSA... ; chiffrement DES, IDEA...), 
r^tat des composants de Tattribut dans I'ensemble 
24 (signd ou non. chiffrd ou non), la cid utilis^e, la 
valeur de la signature.... 

• unedatededemi^remised jourde I'attribut opaque 
20concernd ; ... 

[0035] La table 23 indique les caractSristiques des 
composants 21 contenus dans I'attribut opaque 20 en 
question. Les caract6ristiques des composants 21 per- 
mettent notamment de retrouver un composant 21 de- 
termine dans i'ensemble 24 des composants 21 . La ta- 
ble 23 comprend : 

• ridentifiant d'un composant 21 sous la forme par 
exemple d'un numdro d'Identification ; 

• un type de codage du composant 21 concern^. Le 
type de codage d^crit le mode de representation 
des composants 21 dans I'attribut opaque 20. Uat- 
tribut opaque est susceptible de contenir des com- 
posants de types varies. Le type permet le contrdie 
du stockage des composants 21 dans I'attribut opa- 
que 20, Torganisation des composants 21 en llste ; 

• des informations complementaires de codage com- 
me par exemple des informations concernant le ty- 
pe multimedia ; 

• une longueur utile de valeur du composant 21 con- 
ceme exprimee en octets ; ... 

[0036] Les composants 21 sont stock^s dans Ten- 
sembie 24 les uns k la suite des autres dans I'ordre dans 
lequel ils ont 6X6 cites dans la table 23. L'identifiant et 
la longueur utile indiques dans la table 23 pemnettent 
de retrouver un composant 21 determine dans I'ensem- 
ble 24. 

[0037] L'attribut opaque 20 permet de regrouper des 
composants 21 de types differents et de permettre 
I'ajout, la modification ou la suppression d'un attribut 6, 
20 Gt/ou d'un composant 21 sans inten/enir sur le sche- 
ma de I'annuaire 4. 

[0038] Sebn une fonrDe de realisation, les types de 
codage determines dans la table 23 se divisent en trois 
categories : les types simples, les types multimedia, les 
types constructeurs. 

[0039] Les types simples comprennent le type texte 
(« TEXT » en annexe) qui correspond h une chaine de 
caracteres (texte quelconque). le type entier de valeur 



binaire. le type numerique (caracteres numehques de 0 
k 9), le type bit qui correspond k un champ d'octets. le 
type booieen (valeur vrai ou faux), le type enumere dont 
la valeur est associee k une constante. le type secret 
(texte special de type chiffre et de longueur quelcon- 
que), le type date/heure (format de date/heure etabli). 
[0040] Les types multimedia comportent le type ima- 
ge, le type son et le type video. 
[0041] Les types constructeurs introduisent et deiimi- 
tent des structures telles que des listes. Le type llste (« 
LIST » en annexe) repr6sente une liste de n occurren- 
ces d'une structure, le nombre maximum d'occurrences 
etant fixe. Le type fin de liste (« END » en annexe) cidt 
la description d'une llste. Les types constructeurs auto- 
risent I'imbrication des listes; n niveaux d'imbrication 
sont possibles. Des regies- d'utillsation accompagnent 
les types constructeurs. 

[0042] Tout autre type est susceptible d'etre utilise. 
[0043] Les fonctions 15 d'acces permettent I'acces 
aux attribute 6, 20 de I'annuaire 4. Les fonctions 1 5 d'ac- 
ces permettent d'extraire. d'introduire, de modifier ou de 
supprimer des attributs dans I'annuaire 4. Les fonctions 
15 mettent les attributs extraits de i'annuaire 4 a la dis- 
position des fonctfons 14 de gestion dans la memoire 
tampon 18. Les fonctions 14 de gestion creent, modi- 
fient, suppriment des attributs et/ou des composants et 
transmettent le resultat des operatk>ns aux fonctions 1 5 
d'acces par Tintermediaire de la memoire tampon 18: 
les fonctions 15 d'acces introduisent les attributs et/ou 
composants crees ou nrKxiifies par les fonctions 1 4 dans 
I'annuaire 4, ou encore suppriment de I'annuaire 4 les 
attributs et/ou composants supprimes par les fonctions 
14 de gestion. 

[0044] Les fonctions 1 4 de gestion sont prevues pour 
{'exploitation des attributs opaques 20 de maniere inde- 
pendante k i'annuaire 4. 

[0045] Les fonctions 1 4 de gestion permettent d'intro- 
duire ou de supprimer des attributs standards 6 dans 
des objets 5, des composants 21 dans des attributs opa- 
ques 20 ou des attributs opaques 20 dans des objets, 
de lire ou modifier des attributs standards 6 ou des com- 
posants 21 des attributs opaques 20, en s'appuyant si 
necessaire sur une description 25 formelte compiiee et 
stockee dans I'annuaire 4. Les fonctions 14 de gestbn 
sont susceptlbles de lire les composants 21 des attributs 
opaques 20 sans faire appel k la description 25 corres- 
pondante: les fonctions 14de gestion doivent alors con- 
naitre l'identifiant du composant recherche (l'identifiant 
d'un attribut opaque est donne par la table 23 dudit at- 
tribut). L'attribut opaque contient le minimum d'informa- 
tions permettant aux fonctions de gestion 14 de lire les 
composants qu'il contient sans informations suppie- 
mentaires. II est ^ noter que la lecture est I'operation la 
plus frequente statistiquement. Pour toute autre opera- 
tion telle la creation, la modification ou la suppression 
d'un attribut 6, 20 ou d'un composant 21 , la fonction 14 
de gestion requiert les informations de la description 25 
compiiee. Lore d'operations de mise k jour (creation. 
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modification ou suppression), des controles sont neces- 
saires tels que des contrdles sur les longueurs, les ty- 
pes, les masques, fes caractdres obligatoires... : les 
contr6les s'appuient sur les informations comprises 
dans les descriptions 25 compil^es. 
[0046] II est ^ noter que les informations contenues 
dans les descriptions 25 pourraient, selon une forme de 
realisation de rinvention. dtre comprises dans les attri- 
buts opaques 20. Les descriptions 25 compiides am^- 
iiorent les performances du systdme 1 . 
[0047] La description 25 de I'attribut opaque 20 est 
issue des fichiers source 12. Un fichier source 12 est 
reserve pour chaque description 25 et pour chaque ver- 
sion de la description 25. La compilation de la descrip- 
tion 25 s'effectue k partir des fichiers source 12 au 
moyen du compilateur 10. La compilation ameliore les 
performances de traitement 
[0048] La description 25 compilde apporte k I'entite 8 
des informations relatives k un attribut opaque donne 
sans que I'entit^ ait k solliciter i'annuaire 4: la fichier 
source 12 contient des informations telles que le libelle 
exteme de saisle du champ attribut ou composant « LBL 
» comme il sera vu plus loin, assurant une mise en forme 
automatlque des formulaires de saisle de I'interface gra- 
phique 9 de I'entitd 8: interface 9 est g^ndr^e automa- 
tiquement sans avoir recours aux attributs stockes dans 
rannuaire 4. La mdme description 25 est utilis^e pour 
la saisle de donn^es ext^rieures au syst^me 1 et la ges- 
tion de donndes appartenant k I'annuaire 4, ce qui as> 
sure une coherence dans la gestion des informations. 
[0049] Dans la forme de realisation des figures 1 et 3, 
les fichiers source 12 sont enregtstr^s dans la machine 
2b de stockage. Le compilateur 10 de la machine 2b 
transforme le fichier source contenu dans les moyens 
de stockage 11 en une description 25 compilee stockee 
dans I'annuaire 4 de ia machine 2a annuaire. La des- 
cription compil6e Ii6e k un objet 5 donn§ est stockee par 
exemple (figure 1) dans un objet 26 special. Le fichier 
compile bendficie des capacit^s de distribution des 
technologies d'annuaires. 

[0050] La description 25 compiles permet une evolu- 
tion en douceur du contenu des objets. Selon un exem- 
ple de forme de realisation, la description 25 comporte, 
comme il sera vu plus loin, le num6ro de version du con- 
tenu de Tobjet 5 conceme : revolution de structure des 
objets 5 est geree k I'aide de numeros croissants de ver- 
sion. 

[0051] La gestion des versions est rendue souple et 
efficace. L'annuaire 4 peut evotuer sans cesse sans re- 
mettre en cause les objets existants et le schema de 
I'annuaire. La gestion des versions est assuree par les 
fonctions 14 de gestion lors de la creation ou suppres- 
sion d'objets 5 dans I'annuaire 4. 
[0052] Selon un exemple de realisation de la gestion 
des versions, il est prevu une compatibilite montante en- 
tre la description 25 d'un objet 5 et I'objet 5 effectif exis- 
tant (objet 5 de version V et description 25 de version 
V+n): 



[0053] Dans ce cas, afin d'assurer une totals compa- 
tibilite, c'est k dire une evolution de la structure des ob- 
jets 5 sans remettre en cause les objets existants, les 
regies suivantes sont appliquees dans les fonctions de 
s gestion 14: 

Si un nouveau composant 21 apparait dans la des- 
cription 25, il est visible pour I'entite 8 et indique 
comme absent dans I'objet 5 courant mais ajoute 
10 en mise k jour par la fonction de gestion 14 
concern ee ; 

Si un composant 21 disparait de la description 25. 
il n'est plus visible pour I'entite 8 et est supprime de 
Tobjet 5 ^ la mise k jour par la fonction de gestion 
IS 14concemee. 

[0054] !i est egalement prevu une compatibilite des- 
cendante entre la description d'un objet et I'objet effectif 
existant (objet de version V et description de version V- 

20 n): 

[0055] Cette situation inten/jent dans des periodes 
transitoires de deploiement d'une nouvelle version de 
description d'objet. et de differences dues k la replica- 
tion des objets. 
25 [0056] Dans cs cas, une compatibilite minimum est 
assuree. permettant un fonctionnement transitoire, en 
attendant la mise k niveau de la description. 
[0057] Les regies suivantes sont appliquees : 

30 . Si un composant 21 est present dans la description 
25 mais ne I'est plus dans I'objet 5. fe composant 
21 est consldere comme absent de la description ; 
Si un composant est absent de la description mais 
present dans I'objet, il est considere comme present 
35 dans la description, accessible dans I'annuaire 4 au 
moyen de I'ldentifiant mais pas du nom interne qui 
n'est defini que dans la description. 

[0058] Les modifications k apporter au schema de 
40 i'annuaire 4 sont iimitees : les evolutions sont deportees 
hors de I'annuaire 4. 

[0059] Dans la forme de realisation de la figure 1 , les 
attributs d'une ciasse d'objets 5 sont regroupes en 
items. Une ciasse d'objets peut contenir plusieurs items. 
45 Dans la fomne de realisation decrite, un item est cons- 
titue d'au moins un attribut standard 6 et/ou d'un seui 
attribut opaque 20. Un attribut standard 6 ou un compo- 
sant 21 dans un item est appeie dans ce qui suit un ele- 
ment de I'item. 

so [0060] D'autres items sont susceptibles d'etre crees. 
[0061] Les descriptions 25 sont de deux types : 

• les descriptk)ns 25a d'items ; 

• les descriptksns 25b d'attributs. 

55 

[0062] L'annexe 1 montre un exemple de description 
25 d'items et d'attributs. 

[0063] La description 25a d'items est ref erencee sous 
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la forme <Classe> - <ltem>, <Classe> represenle la 
classe de Tobjet 5 concerne, <ltem> Titem concern^ (en- 
semble de composants d'un attribut opaque ou ensem- 
ble d'attributs standards dans ladite classe d'objets en 
question). Les items clt6s sont ddclards au prdalable 
comme appartenant k la classe d'objets correspondante 
dans I'annuaire 4. Un fichier source 12 peut comporter 
une description d'items et une suite de descriptions d'at- 
tributs correspondants. 

[0064] La description 25 d'items comprend les Infor- 
mations survantes : 

• la classe de I'objet concern^, appel^e « CLASS ». 
Les classes sont identifides par des mots elds rd- 
serves. 

• les items declares dans un objet qui dependent de 
la classe de Tobjet en question, appel^s «< ITEM ». 
Une classe d'objets est constitute de plusieurs 
items. Pour chaque classe. la liste des items qu'il 
doit/peut contenir est d§finie. A chaque type d'item 
est associt un identifiant unique. Dans la forme de 
rdaiisation d^rite, les identifiants sont : 

• « BASE attributs standards 6 ; 

« XXX » (tout terme different du terme BASE 
utilise pour les attributs standards) : attributs 
opaques 20. 

• la version de la description de I'item, appeite « 
VERSION ». Cette infomiation est tr^s importante : 
elle assure une evolution compatible de la descrip- 
tion des items. 

• la liste des iangues a utiliser, appelte « LANGUA- 
GES » telles que par exemple la langue utilisee 
pour les libell^s d'attributs, ... ; une description re- 
qulert au moins une langue. Si une des Iangues 
n'est pas foumie explicttement pour un attribut, on 
prend par dtfaut la premiere langue ddflnle dans la 
description pour I'attribut en question. 

[0065] La description 25 d'items peut dgalement com- 
prendre des infomriations de sdcuritd optlonnelles. Les 
informations sont dites optlonnelles car elles impliquent 
une option par difaut en cas d'absence. Les informa- 
tions de s^uritd sont ddfinies dans I'en-tdte 22 de I'at- 
tribut opaque 20 et/ou dans la description 25a d'items 
selon les besoins (options de stcuritd g^ntrales et/ou 
pour seulement certains attributs). La protection des at- 
tributs opaques 20 s'effectue par chiffrement et/ou si- 
gnature. Par ddfaut, par exemple. les attributs opaques 
ne sont ni signds ni chiff rts. Les param^tres optionnels 
de la description 25a autorisent la modification des va- 
leurs de protection par d6faut. 
[0066] Selon une forme de realisation, les param^tres 
optionnels sont : 



• la signature de I'attribut en question ; 

• • le chiffrement de I'attribut concerne ; dans le cas 
d'un chiffrement requis, les composants 21 de type 
secret ne sont pas chiff rts individuellement. 

s • \e niveau de chiffrement pour I'attribut en question. 

[0067] La description 25b d'attributs permet : 

• d'identifier chaque 6l6ment de I'objet concerne par. 
10 un nom interne et un identifiant, d'indiquer la cor- 

respondance entre le nom interne et ('identifiant 
pour un 6l6ment donn6 ; 

• de definir les types des elements de i'objet 
concern^ ; 

IS • de foumir des informations utilisabies par les fonc- 
tions de gestldn 1 4 des didments 21 ou directement 
par Tentitd 8 (interface graphique 9) telles que : 

un libelie(s) du champ de saisie de i'6l6ment ; 
20 . une indication du statut obligatoire ou optionnel 
de r6l6ment ; 

une taille minimum / maximum ; 
des contraintes sur I'eltment ; 
des informations compl6mentaires sur rele- 
ts ment. 

[0068] La description comprend : 

• le nom interne de ('element concern^, appele <« ATT 
30 ». Le nom interne pemnet de nommer simplement 

un 6l6ment (attribut standard 6 / composant 21 d'un 
attribut opaque 20). II sert de reference pour la ges- 
tion ulttrieure des descriptions d'items et pour I'ad- 
ministration de i'annuaire 4. Le nom interne est in- 

3S dependant du nom defini dans le schema de I'an- 
nuaire 4. Le nom interne identifie chaque didment ; 
il est unique pour un objet 5 donn6. Selon un exem- 
ple illustratif, le nom est donne sur 12 caractdres 
nnaximum. Le nom doit commencer sur le premier 

40 caractdre de la ligne ; 

• I'identifiant, appelt i'OID. L'identifiant identifie cha- 
que diSment; il est unique pour un item donnd. 
Uidentifiant est Inddpendantde ridentification dans 

45 I'annuaire 4. 

• le nom de rtltment dans i'annuaire 4 utilise par I'in- 
terface 7 et obligatoire dans la description des at- 
tributs 6 standards, appeld « XNM ». II est codd par 

so exemple sur 36 caractdres maximum ; 

• I'indication de i'dtat de r616ment au niveau de I'en- 
tit6 8, appel6 « HID ». L'§tat de I'6l6ment peut pren- 
dre les valeurs caches ou visibles. L'HID est declare 

ss avant les options qui suivent ; 

• le libelid externe de saisie du champ element tel que 
prdsentd au niveau de I'entitd 8, appele <« LBL » ; 
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• le type de codage de r^idment parmi ceux 6nonc6s 
pr6c6demment, appele « TYP 

[0069] D'autres options sont susceptibies d'dtre utili- 
s^es telies que par exemple des options qui sont fonc- s 
tion du type de codage de I'§l6ment. Quelques exem- 
ples sont donnas ci-apr^s permettant de comprendre 
I'exemple de fichiers source donne en annexe. 

• Toption « MDT » determine le statut obligatoire ou 
optbnnel de I'dl^ment ; 

• Toption «< RNG » represente la piage de longueur 
(chaTne de caract^res, num6rique, secret) ou de va- 
ieur (entier), ou le nombre d'occurrences minimal et 
maximal (type constructeur). 

• Toption « SZF » definit la taille du champ de saisie 
pour rinterface graphique 9 de i'entitd 8. 

• « CAS » definit la casse pour les types chaTnes de 
caractdres ; 

« FREE », la casse est respect^e ; 
cc UP », les majuscules sont torches ; 
« LOW ». les minuscules sont foresee. 

[0070] Les Informations donnees par la description 
telies que t'option SZF par exemple permettent la mise 
en forme automatique (sans avoir recours k des modu- 
les supplementaires) des formulaires de saisie de rin- 
terface graphique. 

[0071] Des options sont h pr^voir dgalement par 
exemple pour les types multimedia tels que : 

• roption « PLD » indlquant le pr^chargement auto- 
matique des types multim6dias dans la structure. 

• I'option « ALG » qui est un identifiant d'algorithme. 

[0072] Les identifiants d'algorithme pour le type ima- 
ge sont par exemple : 



0 


GIF 


1 


JPG 


2 


TIF (fractales) 


3 


Ondelettes 



Des identifiants sont 6galement determines pour les ty- 
pes sons et vid6o. 

[0073] La manipulation des elements s'effectue k 
I'aide des fonctions de gestion 14 en pr^cisant I'item. 
Litem doit §tre precise k Tappel afin que les fonctions 
determinent la structure concernee par l'op6ration k ef- 
fectuer. 

[0074] Les fonctions de gestion 1 4 permettent de ma- 
nipuler (creer, lire, modifier, supprimer, afflcher) les don- 
nees suivantes : 



• attributs standards des objets de Tannuaire 4 ; 
attribute opaques des objets de I'annuaire 4 et com- 
posants 21 de ces attributs ; 
composants de security de base integr^s dans des 
attributs des objets 5... 

[0075] Les elements manipules par les entltes 8 sont 
contrdies, filtres par tes fonctions 14 de gestion. 
[0076] Si la fonction de gestion 1 4 appeiee necessite 
les descriptions 25a et b compiiees de I'objet, lesdites 
descriptions sont chargees automatiquement par la 
fonction de gestion en question. Selon une forme de 
realisation particuliere de realisation, les descriptions 
compiiees sont chargees dans la memoire tampon 18. 
Les fonctions de gestion 14 puisent dans les descrip- 
tions compiiees les infomnations necessaires aux ope- 
rations qu'elles doivent effectuer. Les fonctions de ges- 
tion 1 4 s'appuient sur la description 25a d'ltem pour con- 
nattre la classe d'objet et I'item concernes. 
[0077] Les fonctions de gestion dans la forme de rea- 
lisation decrite sont tes suivantes : 

une fonction d'initialisation d'objets InitObj : I'appel 
k cette fonction permet d'initialiser la structure d'un 
nouvel objet ainsi que la structure d'attributs 6,20 
de I'objet cree de maniere k pouvoir y inserer des 
attributs standards 6 ou des composants 21 . L'objet 
5 est defini k I'appei de la fonction dinitlalisation en 
precisant la classe de I'objet, I'item correspondant 

une fonction de rangement PutElem : la fonction de 
rangement realise la creation ou mise k jour d'un 
attribut 6,20 ou d'un composant 21 d'un attribut opa- 
que 20. A I'appel de la fonction de rangement sont 
precises la version, la classe. I'identifiant ou le nom 
de I'eiement, i'occurrence en cas de liste, la lon- 
gueur utile dans le cas de types bit ou secret, le type 
de codage de rei6ment. La fonction de rangement 
actualise pour chaque objet traite une liste des at- 
tributs modifiees afin d'optimiser la mise k jour. 

une fonction de lecture GetElem : la fonction de lec- 
ture assure I'extraction d*un attribut 6, 20 ou d'un 
composant 21 d'un attribut opaque 20 de I'annuaire 
4. Si le composant demand6 est recherche par son 
identifiant d'objets, la fonction de lecture n'a pas k 
charger la description compiiee : la table 23 inte- 
gree de I'attribut est suffisante. A i'appel de la fonc- 
tion de lecture, sont precises la version, la classe. 
I'identifiant ou le nom de I'eiement, I'occurrence en 
cas de liste, la longueur utile dans le cas de types 
bit ou secret, le type de reiement. 

une fonction de suppression RemElem : la fonction 
de suppression effectue la suppression de la valeur 
d'un attribut 6.20 ou d'un composant 21 d'un attribut 
opaque 20, d'une occurrence d'une liste de compo- 
sants dans un objet. A I'appel de la fonction de sup- 
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pression, sont precises la version, la classe, I'tden- 
ttfiant ou le nom de I'dtdment, i'occurrence en cas 
de liste, la longueur utile dans ie cas de types bit ou 
secret, le type de codage de I'dl^ment. 

une fonclion de verification CheckObj : ISlbnction 
de verification verifie les attributs 6,20 d'un objet et 
les composants 21 d'un attrlbut opaque 20 avant 
validation d'une creation ou d'une modification. La 
fonction de verification permet le contrdle de pre- 
sence obligatoire des attrlbuts/composants. Elle 
peut dtre appeiee par une entite 8. mais elle peut 
egalement dtre mise en oeuvre systematiquement. 
A I'appel de la fonction de verification, sont precises 
la version, ia classe. I'identifiant ou le nom de i'eie- 
ment, roccunrence en cas de liste, la longueur utile 
dans le cas de types bit ou secret, le type de codage 
de i'eiement. 

[0078] L'entite 8 appelle une fonction 1 4 de gestion 
en pla^ant les parametres necessaires k ladite fonction 
14 dans la structure de communication 17. structure 
de communication 17 se presente sous la fomne d'une 
succession de tous les parametres necessaires k toutes 
les fonctions 14 de gestion. La fonction 14 de gestion 
appeiee recupere dans la structure 17 de communica- 
tion les valeurs de parametres qui Tinteressent. 
[0079] Les fonctions 1 4 de gestion renvoient un code 
retour indiquant si la fonction a ete correctement effec- 
tuee, si une erreur est intervenue, si les parametres 
d'appel sont corrects, si la description compiiee a ete 
retrouvee, si I'objet existe ... 
[0080] Les fonctions 14 de gestion sont con^ues de 
maniere ^ suivre les regies de gestion de versions enon- 
cees plus haut. 

[0081] Les fonctions 1 4 de gestion pemnettent de lire 
une suite d'attributs/ composants sans solliciter I'an- 
nuaire 4. 

[0082] Les fonctions 1 4 de gestion assurent le chiffre- 
ment/dechiffrement et la signature des composants 21 
contenus dans Tattribut opaque 20. Les fonctions de 
gestion communiquent avec le module de securite 19 
pour effectuer les operations de securite (signature, 
chlffrement, ...) requises dans une description d'item 25 
et/ou dans I'en-tete 22 d'un attribut opaque. It est ^ noter 
que le module de securite 19 est independant : l'entite 
8 peut faire appal directement au module de securite 
comma le montre la figure 1 . 

[0083] Le systeme 1 decrit fonctionne de la maniere 
suivante : 

[0084] Lorsque l'entite 8 souhaite creer un objet dans 
I'annuaire 4, l'entite 8 commence par appeler la fonction 
de gestion 14 ^initialisation : l'entite 8 introduit les pa- 
rametres d'appel suffisants dans la structure de com- 
munication 17. La fonction 14 ^initialisation extrait de 
ladite structure les parametres qui lui sont necessaires, 
charge la description 25 compiles correspondante dans 
la memoire tampon 18 et cree la structure de depart 



d'objet souhaitee en definissant des valeurs par defaut. 
La structure est enregistree dans la memoire tampon 
18. La structure cr6ee, la fonction 14 d'initialisation in- 
dique k l'entite 8 que la structure est prSte d recevoir 

s des attributs standards 6 ou des composants 21 en ren- 
voyant un code retour adapte dans la structure de com- 
munication 17. Comme indique plus haut, divers codes 
retour sont susceptibles d'etre transmis k l'entite 8 pour 
lui indiquer I'etat de fonctionnement. Lorsque Tentite de- 

10 tecte le code retour indiquant que la structure de depart 
a ete creee, rentlte 8 appelle alors ta fonction 1 4 de ges- 
tion de rangement: elle transmet k la structure de com- 
munication les caracteristiques des attributs standards 
6 ou des composants 21 qu'elle souhaite introduire dans 

IS Tattribut opaque 20 conceme. La fonction 14 de range- 
ment les recupere et remplit la structure d'objets prece- 
demment creee dans la memoire tampon 18 en s'ap- 
puyant sur la description compiiee chargee. La fonction 
14de rangement peut egalement faire appel au module 

20 19 de securite en cas de signature ou de chiffrement 
des informations contenues dans I'objet conceme. Lors- 
que I'objet est pret k etre transfere dans I'annuaire 4. 
l'entite 8 a le choix entre valider la creation ou la verifier 
sachant qu'en validant, I'operation de verification est 

25 egalement realisee. La verification avant validation per- 
met d'obtenir precisement toutes les erreurs realisees. 
L'operation de verification est effectuee par la fonction 
de gestion de verification. Lorsque l'entite 8 valide la 
creation, la fonction 15 d'acces transfere I'objet cree et 

30 renseigne dans I'annuaire 4. 

[0085] Lorsque l'entite 8 souhaite modifier un objet 
dans I'annuaire 4, l'entite 8 commence par appeler la 
fonction 15 d'accds. La fonction 15 d'acces retrouve 
I'objet dans I'annuaire 4 et en transfere une copie dans 

35 la memoire tampon 18. La fonction 15 d'acces indique 
par code retour k l'entite 8 que I'objet a ete correctement 
transfere dans la memoire tampon 18. L'entite 8 appelle 
alors la fonction 14 de gestion de rangement : elle trans- 
met k la structure de communication 17 les caracteris- 

40 tiques modifiees de I'attribut standard 6 ou du compo- 
sant 21 de I'attribut opaque 20 conceme. La fonction 14 
de rangement extrait les parametres qui lui sont neces- 
saires de la structure de communication 17 et charge ta 
description compiiee correspondante dans la memoire 

45 tampon 1 8. La fonction 1 4 de rangement modifie I'objet 
en question enregistre dans la memoire tampon 18 par 
la fonction d'acces 15. comme indique par les parame- 
tres de la structure de communication transmis par l'en- 
tite 8 et conformement k la description compiiee. La 

so fonction de rangement peut egalement faire appel au 
module de securite 19 en cas de signature ou de chlf- 
frement des informations contenues dans I'objet concer- 
ne. Lorsque I'objet est pret k §tre transfere dans I'an- 
nuaire 4, l'entite 8 a le choix entre valider la creation ou 

55 la verifier sachant qu'en validant, l'operation de verifica- 
tion est egalement r6alisee. La verification avant valida- 
tion permet d'obtenir precisement toutes les erreurs rea- 
lisees. L'operation de verification est effectuee par la 
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fonclion de gestion de verification. Lorsque Tentit^ 8 va- 
lide la modification, la fonction 1 5 d'acc6s transf^re I'ob- 
jet modifie de la m^moire tampon 18 dans Tannuaire 4. 
[0086] Lorsque Tentitd 8 souhaite supprimer un attri- 
but 6. 20 ou un composant 21 de I'annuaire 4, 1'entitd 8 5 
commence par appeler ia fonction 1 5 d'accds. La fonc- 
tion 15 d'acc^s retrouve I'objet dans Tannuaire 4 et en 
transf^re une copie dans la m^moire tampon 18. La 
fonction 15 d'acc^s indique par code retour h I'entitd 8 
que robjet a dtd correctement transf erd dans la mdmoire io 
tampon 1 8. L'entitd 8 appelle alors la fonction 1 4 de ges- 
tion de suppression : elle transmet k la structure de 
communication les caract^ristiques de i'attribut stan- * 
dard 6 ou du composant 21 k supprimer de I'attribut opa- 
que 20 concerne. La fonction 1 4 de suppression extrait is 
les param^tres qui lui sont n^essaires de la structure 
de communication 17 et cfiarge la description compil^e 
correspondante dans la memoire tampon 18. La fonc- 
tion 14 de suppression supprime le composant 21 ou 
Tattribut 6.20 en question enreglstr§ dans la mdmolre 20 
tampon 18 par la fonction d'accds 15, comme indiqud 
par les paramdtres de la structure de communication 
transmis par Pentite 8 et conform6ment k la description 
compilee. La fonction 15 d'acc^s supprime I'attribut 6, 
20 ou le composant 2 1 indique dans la m6molre tampon 25 
18 dans I'annuaire 4. 

[0087] Lorsque Tentitd 8 souhaite lire un objet dans 
I'annuaire 4. 1'entitd 8 commence par appeler la fonction 
1 5 d'acc^s. La fonction 1 5 d'acc6s retrouve I'objet dans 
I'annuaire 4 et en transfdre une copie dans la memoire 30 
tampon 18. La fonction d'acc^s indique par code retour 
k ('entity 8 que I'objet a 6t6 correctement transf 6r6 dans 
la memoire tampon 18. L'entit6 8 appelte alors la fonc- 
tion de gestion 14 de lecture. Si les parametres foumis 
par I'entite 8 sont suffisants et en particulier si le nom 3S 
interne de I'attribut standard ou du composant a dtd don- 
n6, la fonction de lecture n'a pas besoin de charger la 
description compilee. Oans le cas contraire, la descrip- 
tion compilde est chargde de mani^re k obtenir la cor- 
respondance entre le nom interne et ridentlfiant. La 40 
fonction 1 4 de lecture v^rifie dventuellement si ('entity 8 
a le droit de lire les informations concern^es en faisant 
appelau module de sdcurit^ 1 9. Elle d6chiffre ^ventuel- 
lement lesdites informations et ve rifle leur integrity. Elle 
retrouve les informations souhait^es de I'objet en par- 
courant I'ensemble 24 des valours k I'alde de I'identifiant 
ou libelld et de la longueur utile. Elle place lesdites in- 
formations dans la structure de communication 1 7. L'en- 
tite 8 n'a plus qu'ei lire les informations requises dans la 
structure de communication 1 7. so 
[0088] Selon un ddveloppement de I'lnvention, les 
versions de description antdrieures k une version utili- 
s6e k un instant t sont archiv^es dans un repertoire 
s^pard . Les versions de description anterieures peu- 
vent etre archiv6es par exemple en ajoutant au nom un ss 
suffixe reprdsentant le numdro de version. 
[0089] La pr6sente invention concerne done un pro- 
cede de gestion de i'annuaire 4 ou equivalent compor- 



tanl les objets 5 caracterises par les attributs standards 
6, I'annuaire 4 etant apte k dtre interroge par I'entlte 8, 
caracterise en ce qu'll consiste k caracteriser les objets 
5 par les attributs specifiques 20 dits attributs opaques 
20, presentant la meme structure externa que les attri- 
buts standards 6 et dont la structure interne permet de 
definir et administrer les composants 21 de manidre in- 
dependante k Tannuaire 4. 

[0090] Le procede selon invention consiste k definir 
et administrer les composants 21 au moyen de interfa- 
ce de programmatron au niveau applicatif AP1 13 entre 
I'annuaire 4 et i'entitd 8. 

[0091] Le procede consiste k definir la structure inter- 
ne de I'attribut opaque en trols parties : 

• I'en-tete 22 deiivrant des informations generales sur 
Tattribut opaque 20 ; 

la table 23 de caracteristiques des composants 21 ; 
- I'ensemble 24 de valeurs des composants 21 indi- 
ques dans la table 23. 

[0092] Le procede consiste k Integrer dans la struc- 
ture interne de I'attribut opaque 20 des informations de 
securite assurant I'integrite, I'origine et/ou laconfidenti- 
alite des composants 21 contenus dans I'attribut 20. 
[0093] Le procede consiste k integrer dans ia struc- 
ture interne de I'attribut opaque 20 des informations per- 
mettant la gestion de drfferentes versions du contenu de 
I'attribut 20. 

[0094] Le procede consiste k integrer dans la struc- 
ture Interne de Tattribut opaque 20 le type de codage de 
chaque composant 21 contenu dans ledtt attribut 20. 
[0095] Le procede consiste k lire ou mettre k jour, k 
savoir creer, modifier, lire ou supprimer, un attribut stan- 
dard 6, un attribut opaque ou un composant 21 dans un 
attribut opaque 20 de maniere independante k Tannuai- 
re 4 au moyen des fonctions de gestion 14 des attributs 
opaques 20 appeiees par I'entite 8. 
[0096] Les fonctions 14 de gestion s'appuient sur la 
description 25 des attributs 6,20 pour effectuer leur mise 
k jour, ainsi que leur lecture si I'entite 8 n'a pas fourni 
les Infomiatlons suffisantes pour acceder directement k 
I'attribut concerne dans I'annuaire 4. 
[0097] Le procede consiste k compiler la description 
25 k I'alde d'un compilateur 10. 
[0098] Le procede consiste k integrer dans la descrip- 
tion 25 des informations de securite assurant t'integrite, 
I'origine et/ou la confidentialite des composants 21 con- 
tenus dans I'attribut 20. 

[0099] Le procede consiste, au moyen des fonctions 
15d'acces k Tannuaire 4, k extraire, introduire, modifier 
ou supprimer des attributs 6,20 dans I'annuaire 4 con- 
formement aux operations effectuees par les fonctions 
14de gestion. 

[0100] La presente invention porte egalement sur le 
systeme informatique permettant la mise en oeuvre du- 

dit procede. 

[0101] l^a*presente invention se rapporte k un syste- 
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me infornnatique comprenant au moins une machine 2 
munte de Tannuaire 4 ou equivalent susceptible d'etre 
interroge par Tentitd 8. caract^ris6 en ce qu'il comprend 
i'interface de programmation au niveau applicatif AP1 1 3 
entre I'annuaire 4 et I'entitd 8 comprenant les fonctions 
15 d'acces k Tannuaire 4 et les fonctions 14 de gestion 
d'atthbuts standards 6 et/ou d'attributs opaques 20. 
[0102] L*entit6 8 communique avec I'interface AP1 1 3 
au travers de ia structure de communication 17 enregis- 
tr^e dans les moyens de memorisation 16. 
[01 03] Le syst^me comprend les moyens 1 1 de stoc- 
kage des fichiers source 12, le compilateur 10 desdits 
fichiers 1 2. 

ANNEXES 



LBL=FR="Telephone usager" 

MDT=N 

RNG=16 

S2F=16 

5 CAS=:UP 

/ description 25 d'un item attribut opaque SECITEM 20 
de la classe d'objets PERSON 
/ description des composants de I'attribut opaque, dans 
10 I'item SECITEM 

CLASS=PERSON 
ITEM=SECITEM 
VERSION=001 
IS LANGUAGES=EN,FR 



Exemples de fichier source 12. 

[0104] / description 25 de I'item BASE de la classe 
d'objets Personne 20 

CLASS=PERSONNE 

ITEM=BASE 

VERSION=001 

LANGUAGES=:EN,FR 2S 



/description 21 des attributs standards 6 de I'item 



BASE 



/ description 25 des attributs opaques 20 de I'item 
/ definition de la liste des ressources accorddes 

ATr=LISTRAL 
OID=100 

LBL=EN=*Resource allocated list" 

LBL^FR=''Liste des ressources altouees' 

TYP=LIST 

PRS=PCM 

RNG=500 

/ classe des ressources de la liste 



ATT=CNAME 

OID=0001 

XNM=commonName 
HID=N 

LBL=EN='User common name" 

LBL^FRzi^ident X500 de I'usager" 

TYP=TEXT 

MDT=Y 

RNG=64 

SZF=24 

CAS=FREE 

ATT=SURNAME 

OID=0002 

XNM=surname 

HIDrN 

LBLsENs'liser surname' 

LBL=FR=:"Patronyme X500 de Tusager" 

TYPrTEXT 

MDT=Y 

RNG=32 

SZF=16 

CAS=LOW 

ATTxTELEPHONE 
OID=0003 

XNM= telephoneNumber 
HID=N 

LBL^ENzi'User telephone" 



30 ATT=OBJECTCLASS 

OID=101 

LBL=EN="Resource class" 
LBL=FR=''Classe de la ressource" 
TYP=TEXT 
35 RNG=48 
CAS=UP 

/ nom de la ressource 

40 ATT=OBJECTID 
OID=102 

LBL=:EN="Resource name" 
LBL=FR="Nom de la ressouce" 
TYP=TEXT 
45 MDT=N 
S2F=48 
RNG=96 
CAS=UP 

SO I fin description de la liste (d'une occurrence liste) 

ATTzrENDOFLIST 
OlDrlOO 
HiD=Y 
55 TYP=END 

/ exemple de description des droits d'acces aux noeuds 
et objets 



in 
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/ droit sur le niveau noeud 

An=NODERGT 

OID=:102 

HID=N 

LBL=EN='Rights on node" 

LBL=FR="Droits sur le noeud" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=UP 

ATT=CHiLDGRGT 

OID=103 

HID=N 

LBL=EN='General rights on attached objects" 

LBL=FR="Droits g6n6raux sur les objets ratta- 

ch^es" 

TYP=TEXT 

MDT=N 

RNG=a 

CAS=UP 

An=CLASSRGT 

010=104 

HID=N 

LBL=EN="Speclfic rights on attached objects' - 

LBL=FR="Droits sp6clfiques sur les objets ratta- 

chdes" 

TYP=TEXT 

MDT=N 

RNG=8 

CAS=:UP 



Revendications 

1. Precede de gestion d'une base de donnees (4) ou 
annuaire ou ^uivalent comportant des objets (5) 
caract^rises par des attributs standards (6), la base 
(4) etant apte k §tre interrog6e par une application, 
un utilisateur ou autre appelS entity (8), caractSrise 
en ce qu'il consiste k caractdriser les objets (5) par 
des attributs sp^cifiques (20) dits attributs opaques 

(20) . pr^sentant la m§me structure exteme que les 
attributs standards (6) et dont la structure interne 
permet de d^finir et administrer des composants 

(21) de mani^re inddpendante k la base (4). 

2. Procdd^ selon la revendication 1 , caract^risd en ce 
qu'il consiste k d^finir et administrer les compo- 
sants (21) au moyen d'une interface de program- 
mation au niveau applicatif API (13) entre la base 
(4) et I'entitd (8). 

3. Proc6d6 seton I'une des revendications 1 ou 2, ca- 
ract^risd en ce qu'il consiste k d^finir la structure 
interne de I'attribut opaque en trois parties : 



- un en-tete (22) delivrant des informations g§- 
ndrales sur I'attribut opaque (20); 
une table (23) de caract^ristiques des compo- 
sants (21); 

s • un ensemble (24) de valeurs des composants 
(21) indiquds dans ia table (23). 

4. Procedd selon I'une des revendications 1 k 3, ca- 
ract6ris6 en ce qu'il consiste k int^grer dans la 
10 ' structure Interne de I'attribut opaque (20) des infor- 
mations de s^curit^ assurant I'tnt^gritd, Torigine et/ 
ou la confidentiality des composants (21 ) contenus 
dans I'attribut (20). 

IS 5. Proc^dd* selon Tune des revendications 1 k 4. ca- 
ractdrise en ce qu'il consiste k int^grer dans la 
structure interne de I'attribut opaque (20) des infor- 
mations permettant la gestion de differentes ver- 
sions du contenu de Tattribut (20). 

20 

6. Proced6 selon I'une des revendications 1 k 5, ca- 
ractdrisd en ce qu'il consiste k intdgrer dans la 
structure interne de I'attribut opaque (20) le type de 
codage de chaque composant (21 ) contenu dans 

2S {edit attrlbut (20). 

7. Procede selon I'une des revendications 1 k 6, ca- 
ractdrisd en ce qu'il consiste k lire ou mettre k jour, 
^savoircr^er, modifier, lire ousupprimer, unattribut 

30 standard (6), un attribut opaque ou un composant 
(21 ) dans un attribut opaque (20) de maniere inde- 
pendante k la base (4) au moyen de fonctions de 
gestion (14) des attributs opaques (20) appelSes 
par I'entitd (8). 

35 

8. Procddd selon la revendication 7, caractdrisd en ce 
que les fonctions (14) de gestion s'appuient sur une 
description (25) des attributs (6,20) pour effectuer 
leur mise k jour, ainsi que ieur lecture si I'entitd (8) 

40 n'a pas fourni les informations suffisantes pour ac- 
ceder directement a I'attribut concern^ dans la base 
(4). 

9. Proc6dd selon la revendication 8. caract^risd en ce 
45 qu'il consiste k compiler la description (25) k I'aide 

d'un compilateur (10). 

10. Proc6d§ selon I'une des revendications 8 ou 9, ca- 
ract^rise en ce qu'il consiste k integrer dans la des- 

so cription (25) des informations de sdcuritd assurant 
I'integritd, I'origine et/ou la confidentiality des com- 
posants (21) contenus dans I'attribut (20). 

11 . Procedd selon la revendication 7. caractSrise en ce 
55 qu'il consiste, au moyen de fonctions (15) d'acc^s 

k la base (4). k extraire, introduire, modifier ou sup- 
primer des attributs (6,20) dans la base (4) confer- 
moment aux operations effectu^es par les fonctions 
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(14) de gestion. 

12. Syst6me informatique comprenant au moins une 
machine (2) munie d'une base de donn^es (4) ou 
annuaire ou Equivalent susceptible d'dtre interro- s 
gde par une application, un utilisateurou autre, ap- 
pele entite (8), caract^ris^ en ce qu'ii comprend une 
Interface de programmation au niveau applicatif 
API (13) entre la base (4) et Tentite (8) comprenant 
des f onctions (15) d'acc^s ^ la base (4) et des tone- io 
tions (14) de gestion d'attributs standards (6) et/ou 
d'attributs opaques (20). 

13. Systdme selon la revendication 12, caract6ris6 en _ 
ce que Tentitd (8) communique avec interface API is 
(13) au travers d*une structure de communication 

(1 7) enregistr^e dans des moyens de memorisation 
(16). 

14. Systeme selon I'une des revendications 12 ou 13, 20 
caract^risE en ce qu'ii comprend des moyens (11) 

de stockage de fichiers source (1 2), un compllateur 
(10) desdits fichiers (12). 

1 5. Systeme informatique permettant la mise en oeuvre 2S 
du proc^dd selon i'une des revendications 1^11. 
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En-tete 

-Version; — 

- Longueur en octets ; 

- Informations de securiie ; - - 

- Date de demiere mise a jour ; 

Table 

■ Identifiant; 

■ Type de codage ; 

■ Infonnatioas comjplementaires de codage ; 
M Longueur utile : 

Ensemble de valeurs 



FIG.2 
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